A typical data storage system operates as a large storage device for one or more external host computers (or simply hosts) by responding to block-based input/output (I/O) requests that direct the data storage system to perform load and store operations. Examples of block-based communications include small computer systems interface (SCSI) commands, Enterprise System Connection (ESCON) signals, Fibre Channel communications, and the like.
In some client/server configurations, hosts operate as servers that provide services (e.g., client-oriented access to a data storage system) to one or more other computers called clients. In contrast to block-based communications which servers and data storage systems use to communicate with each other, clients and servers typically communicate with each other using client-oriented and server-oriented communications (hereinafter, generally referred to as client-oriented communications). Examples of client-oriented communications include Transmission Control Protocol/Internet Protocol (TCP/IP) communications, Gigabit Ethernet signals, Asynchronous Transfer Mode (ATM) communications, and the like.
In one configuration, a client can retrieve data from a data storage system by sending a client-oriented request (e.g., a TCP/IP signal) to a server (i.e., a host). The server then provides a block-based request (e.g., a SCSI signal) for data blocks containing the data to the data storage system. Next, the data storage system provides the requested data blocks (e.g., a SCSI signal) to the server in response to the block-based request. The server then extracts the data from the data blocks, and provides that data to the client (e.g., via a TCP/IP signal). Further details of this configuration will now be provided with reference to FIG. 1.
FIG. 1 shows a conventional data storage network 20 having a client/server configuration which utilizes a data storage system. The data storage network 20 includes a client system 22, a server system 24, and a conventional data storage system 26. The client system 22 runs an application front-end 28, such as a graphical user interface (GUI), that enables a user to communicate with the server system 24. The server system 24 runs an application back-end 30 and a storage manager 32. The application back-end 30 includes a client services module 34 for handling requests from clients, and a back-end processing module 36 for performing back-end processing operations.
As further shown in FIG. 1, the data storage system 26 includes front-end circuitry 38, a cache 40, back-end circuitry 42, and disk drives 44-1, . . . , 44-N (collectively, disk drives 44). The cache 40 operates as a buffer for data exchanged between the server system 24 (an external host system) and the disk drives 44. Additionally, the front-end circuitry 38 operates as an interface between the server system 24 and the cache 40. Similarly, the back-end circuitry 42 operates as an interface between the cache 40 and the disk drives 44.
In some data storage systems, the front-end circuitry 38 includes multiple front-end circuits and the back-end circuitry 42 includes multiple back-end circuits for redundancy (i.e., fault tolerance) and load balancing purposes. An example of such a data storage system is the Symmetrix which is manufactured by EMC Corporation of Hopkinton, Mass.
For illustration purposes, suppose that the data storage network 20 operates as a flight reservation system. That is, suppose that a user can operate the client system 22 to (i) find empty seats on particular flights of an airline, and (ii) purchase tickets to reserve such seats. To this end, the disk drives 44 of the data storage system 26 store a database containing records of all seats for all flights of the airline. The storage manager 32 of the server system 24 operates as a database engine that manages the database, and performs database queries on the database (i.e., performs search and filter operations on the database to find particular records) on behalf of the application back-end 30 running on the server system 24. The client services module 34, which provides client services to the application front-end 28 running on the client system 22 (e.g., finds empty seats on particular flights), is capable of submitting such queries to the storage manager 32 (i.e., database engine). Similarly, the back-end processing module 36, which performs back-end processing on the server system 24 (e.g., allocates and schedules airline resources and inventories, prints tickets for newly reserved seats on a nightly basis, etc.), is also capable of submitting queries to the storage manager 32. In response to the queries from the client services module 34 and the back-end processing module 36, the storage manager 32 communicates with the data storage system 26 using block-based communications (e.g., SCSI signals). An example of such a storage manager is Oracle Database Server which is manufactured by Oracle Corporation of Redwood Shores, Calif. An example of how a user operates the flight reservation system 20 will now be provided.
Suppose that the user wishes to reserve an empty seat on a particular flight. The user enters a request for empty seats on the particular flight using the application front-end 28 running on the client system 22. In response, the client system 22 sends a client-oriented request 46 (e.g., a TCP/IP signal) to the server system 24. The client-oriented request 46 requests all empty seats on the particular flight. In response to the client-oriented request 46, the client service module 34 of the application back-end 36 directs the storage manager 32 (i.e., the database engine) to perform a database query on the database stored in the disk drives 44. In particular, the application server module 34 specifies the particular flight, and indicates that it wants all empty seats on that particular flight. In turn, the storage manager 32 sends a block-based request 48 (e.g., SCSI commands) for the entire database (i.e., all seats for all flights of the airline) to the data storage system 26.
When the data storage system 26 receives the block-based request 48 from the storage manager 32 of the server system 24, the data storage system 26 provides a block-based response 50 (e.g., a SCSI signal) containing the entire database. In particular, if the database is un-cached, the back-end 42 copies the database from the disk drives 44 to the cache 40. Then, the front-end 38 transfers the copied database from the cache 30 to the storage manager 32. If copies of any portions of the database resided within the cache, the front-end 38 can transfer those cached copies from the cache to the storage manager 32 without having to load new copies of those portions from the disk drives 44.
When the storage manager 32 receives the database, the storage manager 32 queries the database to obtain all empty seats on the particular flight. In particular, the storage manager 32 searches the database records which contain all seats for all flights of the airline to determine which seats are for that particular flight, and which of those seats are empty. In some configurations, the transfer of the copied database from the disk drives 44 to the server system 24, and the database query operations, occur incrementally and concurrently to improve response time. The storage manager 32 then provides the query results to the client services module 34 which conveys this information in the form of a server-oriented response 52 (e.g., a TCP/IP signal) to the application front-end 28 running on the client system 22. Once the user knows which seats on the particular flight are empty, the user can reserve one of the empty seats on the particular flight by further communicating with the server system 24 which accesses the database again in a similar manner to that described above.
In some configurations, the server system 24 can use hash tables to improve response times to client-oriented requests. For example, in the above-described flight reservation system, the server system 24 can generate a hash table that identifies all empty seats of all flights, and store that hash table on the data storage system 26. In particular, the back-end processing module 36 of the server system 24 can (i) direct the storage manager 32 to read the entire database from the data storage system 26, (ii) generate a hash table that references all of the empty seats on all of the flights by querying the database, and (iii) store the generated hash table on the data storage system 26. The back-end processing module 36 can do this when server system 24 is less busy (e.g., late at night or early in the morning). When a user at the client system 22 later submits the client-oriented request 46 for all empty seats on a particular flight, the server system 24 can retrieve the hash table (rather than the entire database) from the data storage system 26 and identify the empty seats on the particular flight by searching the hash table. Since the hash table is generally much smaller than the database itself, the server system 24 requires less time to respond to the client-oriented request 46 (i.e., to retrieve and search the hash table) thus providing less network traffic and a response time that is superior to the configuration that requires reading the entire database from the data storage system 26 and searching that database.
Unfortunately, there are deficiencies to the earlier-described conventional data storage network of FIG. 1. First, there typically is a large amount of traffic that passes through the cache 40 of the data storage system 26. For example, in the earlier-described flight reservation scenario, the entire database (e.g., the whole seating plan for all of the airline flights) typically is copied from the disk drives 44 into the cache 40 in response to the block-based request 48 (e.g., a SCSI command), and then transferred from the cache 40 to the server system 24. Such an operation typically results in heavy cache usage that produces congestion within the cache 40 which interferes with other unrelated load and store operations, i.e., creates contention situations requiring coordinated use of the cache 40 in order to handle the other data transfers. Additionally, such an operation typically results in a high retrieval latency, particularly when the size of the database is very large, since larger databases require more time to load from the disk drives 44 and pass through cache 40. Furthermore, such an operation places a heavy incentive on increasing the size of the cache 40 to alleviate the cache utilization issues thus increasing the cost of the cache 40 (i.e., memory costs). Even if the size of the cache 40 is increased in order to decrease cache contention, the opportunity to improve performance by re-using cached data at the data storage system 26 (i.e, data stored in the cache 40) could be minimal since the server system 24 will likely cache the data there as well.
Another deficiency of the conventional data storage network 20 of FIG. 1 is that there typically is a large amount of traffic between the server system 24 and the data storage system 26. In the flight reservation example, the entire database containing seat information for all seats on all flights of the airline is transferred from the data storage system 26 to the server system 24 (e.g., SCSI signals) in response to a single user request for empty seats on a particular flight. Such a transfer results in poor retrieval latency as well as consumes bandwidth between the data storage system 26 and the server system 24 that could otherwise be used for other communications (e.g., bandwidth that the server system 24 or other hosts could use to access other data within the data storage system 26).
A further deficiency of the conventional data storage network 20 of FIG. 1 is that the server system 24 is burdened with having to provide all data access services to all clients (e.g., operations of the client services module 34) as well as traditional back-end processing (e.g., standard operations of the back-end processing module 36). For example, in the earlier-described flight reservation scenario, the storage manager 32 performs database queries for clients (e.g., the client system 22) thus consuming processing cycles that otherwise could be spent elsewhere, e.g., on traditional back-end processing operations. Moreover, the storage manager 32 of the server system 24 is often a bottleneck to clients accessing the data storage system 26.
There are deficiencies with the above-described hash table configuration as well. In particular, the server system 24 is now required to periodically retrieve the entire database from the data storage system 26 in order to generate the hash table. The server system 24 then needs to implement a mechanism to keep the hash table updated and synchronized with the database. Such a mechanism can be extremely complex if multiple servers need to coordinate contention for the hash table as well as for the database itself.
Another deficiency is that some configurations may include multiple server systems 24 for load balancing and/or fault tolerance. In such configurations, the server systems 24 typically coordinate access to the database by communicating with each other through a network, i.e., through xe2x80x9cmultiple server intercommunicationxe2x80x9d. For example, when one server system 24 updates a record, that server notifies the other server systems 24 through the network that it has reserved that record, updates the record and then notifies the other server systems 24 through the network that it has unreserved that record. Accordingly, server systems 24 can create excessive network traffic coordinating access to the database.
In contrast to the earlier-described conventional data storage network 20 of FIG. 1 which has a server system 24 receiving a single client-oriented request (e.g., a TCP/IP request) and submitting a block-based request 48 (e.g., a SCSI command) to the data storage system 26 for an entire database (or hash table) in response to the client-oriented request, the invention is directed to techniques for handling a client-oriented request within a data storage system. Handling of a client-oriented request enables direct communication between clients and the data storage system thus offloading the burden of handling certain client requests from the server. Furthermore, in some situations, such handling of the client-oriented request within the data storage system enables reduced traffic through the cache of the data storage system, and reduced traffic between the data storage system and external devices e.g., results of database queries can be transferred rather than entire databases. For example, if database queries are performed within the data storage system itself, database transfers and extensive multiple server intercommunication through a network can be avoided (e.g., extensive reserve/unreserve notifications between servers becomes unnecessary) since servers no longer need to coordinate database accesses on behalf of clients.
One arrangement of the invention is directed to a data storage system having a set of ports for connecting to an external host (e.g. a server), a cache for buffering data exchanged between the external host and a set of storage devices, and a set of interface circuits including (i) multiple front-end interface circuits interconnected between the cache and the set of ports, and (ii) multiple back-end interface circuits interconnected between the cache and the set of storage devices. The set of interface circuits is configured to receive a client-oriented request (e.g., a Gigabit Ethernet signal) from the external host and perform a server-oriented operation in response to the client-oriented request. By way of example, the external host can be a client, and the server-oriented operation can be a database query (e.g., filter/sort based on field1=xe2x80x9cXxe2x80x9d, field2=xe2x80x9cYxe2x80x9d) performed (within the data storage system) on a database on behalf of the client. Accordingly, a server system does not need to perform the database query as in the conventional data storage network 20 of FIG. 1, and there is no need to transfer the entire database from the data storage system to such a server system. Since the burden of handling such a client-oriented request is not placed on the server system (if one exists), the server system has more capacity to perform other operations such as additional back-end processing operations.
In some arrangements, the client-oriented request identifies a database and a database query operation, and the multiple front-end interface circuits are configured to perform the database query operation on any cached portions of the database residing in the cache in response to the client-oriented request. In these arrangements, the multiple back-end interface circuits are configured to perform the database query operation on un-cached portions of the database residing in the set of storage devices in response to the client-oriented request. Accordingly, the entire database does not need to pass through the cache in response to the client-oriented request. Rather, the interface circuits can perform the database query such that, in response to the client-oriented request, only the results of the query pass through the cache and eventually to the external host.
In one arrangement, the un-cached portions of the database are stored in the set of storage devices in a distributed manner. Here, each of the multiple back-end interface circuits is configured to perform, in response to the client-oriented request, the database query operation on a respective un-cached portion of the database stored in a storage device to which that back-end interface circuit connects. Accordingly, each back-end interface circuit does not need to query the entire database. Rather, each back-end interface circuit can simply query a respective un-cached portion of the database if such a portion exists. The back-end interface circuit can then cache the results of the query (e.g., individual records).
In other arrangements, the client-oriented request identifies a web address. In these arrangements, the multiple front-end interface circuits are configured to provide, from the cache, cached portions of web content corresponding to the web address identified by the client-oriented request in response to the client-oriented request. Additionally, the multiple back-end interface circuits are configured to retrieve, from the set of storage devices, un-cached portions of web content corresponding to the web address identified by the client-oriented request in response to the client-oriented request. That is, the back-end interface circuits can cache the un-cached portions of the identified web content. Accordingly, the data storage system essentially can operate as a web server that services web clients (external hosts) without any need for a dedicated external host to operate as a server system.
In some arrangements, the un-cached portions of web content identify an additional web address. In these arrangements, the multiple back-end interface circuits are further configured to (i) detect the additional web address in the web content while the multiple back-end interface circuits retrieve the un-cache portions from the set of storage devices, and (ii) cache, from the set of storage devices, web content corresponding to the additional web address in response to detection of the additional web address. Accordingly, the data storage system can pre-fetch web content (e.g., another web page, a banner, an image, etc.) that is likely to be requested by a subsequent request to reduce data retrieval latency.
In some arrangements, the client-oriented request identifies a file name and a directory name, and the multiple front-end interface circuits are configured to provide, from the cache, cached portions of a file corresponding to the file name and the directory name identified by the client-oriented request in response to the client-oriented request. In these arrangements, the multiple back-end interface circuits are configured to provide, from the set of storage devices, un-cached portions of the file corresponding to the file name and the directory name identified by the client-oriented request in response to the client-oriented request. Accordingly, the data storage system can essentially operate as a file server that services clients, e.g., a network file system (NFS) server that services NFS clients, without any need for a dedicated external host to operate as a server system.
In other arrangements, the set of storage devices store, in a single directory corresponding to the directory name identified by the client-oriented request, both (i) the file corresponding to the file name and the directory name identified by the client-oriented request and (ii) another file. In these arrangements, the multiple back-end interface circuits are further configured to (i) detect existence of the other file while the multiple back-end interface circuits retrieve the un-cache portions from the set of storage devices, and (ii) cache, from the set of storage devices, the other file in response to detection of the existence of the other file. As such, the data storage system can pre-fetch files in the same directory that are likely to be requested by a subsequent request to reduce data retrieval latency.
In one arrangement, the data storage system further includes a set of network adaptors for sending client-oriented communications to the external host and receiving client-oriented communications from the external host. Here, the set of network adaptors is interconnected between the multiple front-end interface circuits and the set of ports. The set of network adaptors enable external hosts to communicate with the data storage system without using block-based communications (e.g., SCSI commands, ESCON communications, etc.). Even servers, which are configured to access the data storage system in a client-like manner using client-oriented requests, can access the data storage system without using block-based communications.
The features of the invention, as described above, may be employed in data storage networks, systems, devices and methods and other computer-related components such as those manufactured by EMC Corporation of Hopkinton, Massachusetts.